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® The initialization of the system state 
(control store, main memory, lOP 
memory, etc.) to that required before 
the first software instruction (IVlesa 
opcode) can be executed (the so-called 
PrlncOps Boot State) 

® Boot Stages 
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PrincOps Boot State 
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® Operational CP microcode and lOP 
control code is loaded into control store 
and lOP memory 

® Pilot Boot File loader (Germ) has been 
loaded into the appropriate place in 
main memory 

® I/O Page has been mapped to its 
assigned virtual address 

® All other normal real memory (i.e. 
excluding display bank and MM map) 
has been mapped 

® The Mesa emulator has been prepared 
to execute the first Mesa byte code of 
the Germ 
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® Hardware Boot 

reset the hardware 

put the CP in a Wait state 

cause the lOP to start execution at a specific 

address in lOP memory 

''''''icrocode Boot'' 

consists of multiple phases 

saves EProm space 
allows more flexibility with changes 
overlays "one time" boot code 
provides a powerful diagnostic strategy 

function: 

delivers Mesa and I/O microcode to control store 
delivers lOP control program (Domino) to lOP memory 
delivers Germ to main memory 
initializes the VM map, and Mesa emulator 

runs PreBoot diagnostics 

source of boot files: EProm and Boot Device 

allows selection of : 

Boot Device: rigid disk, floppy disk, Ethernet (2 sources) 
Boot Mode: normal boot or diagnostic boot 
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EProm contents 

PreBoot diagnostics 

lOP boot code 

Phase CP microcode boot file 

lOP interrupt links 



Boot concepts 

Boot files and boot blocks 

Processing boot files 

CP execution states 

CP kernel and CP protected areas 
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® Boot files 



name: *.db 

a series of boot blocks, together with a checksum 

boot blocks vary in length 

structure: 



Boot Block 


Boot Block 


Boot Block 


1 1 
1 1 


Boot Block 


Checksum 



Block Header 



Block Body 



Block Header indicates type of block: 



Type 





Type = 0: special block 
Type # 0: control store block 



types of boot blocks: 
control store 
special 

task program counter (TPC) 

U register 

fOP memory 

Ignore 

start fOP address 

last block 

examples of boot blocks: 



Control store block 



TPC block 



lOP memory block 



CS address 



low word of instr. 



middle word of instr. 



high word of instr. 



low word of instr. 



middle word of instr. 
h i gh word of instr. 



n = [1..15] 











X 



TPC value 



t= [0..7] 



Last block 



8 



Last block flags 



1 X 9 


lOP address 


Count (bytes) 


byte 1 


byte 


byte 3 


byte 2 


1 
1 1 


1 
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® Processing boot files 

unpack the boot blocks, i.e. load the data into the 
appropriate part of the Dandelion hardware 
special precautions are needed to process the 
control store and TPC boot blocks 

® CP execution states 

Run state: CP is executing in multitask fashion 
Stopped state: CP is executing in kernel task (7) 
Wait state: CP is not executing 



Special CP microprogram that executes while the 
CP is in the ''stopped" state 
Can communicate with lOP 
Performs memory refresh 
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crocode Boot Phases 
® Phase 

Run PreBoot diagnostics (lOP) 
Determine boot device (lOP, CP) 

- Process "PhaseO.db" (from EProm) boot file (lOP) 

® Phase 1 

- start CP execution of "PhaseO" microcode (lOP) 

=> Load "Initial.db'' boot file (from Boot device) 
into main memory (CP) 

Process "Initial.db" (from main memory) file (lOP) 



Start CP execution of "Initial" microcode (lOP) 

=> Load "Mesa.db" boot file (from Boot device) 
into main memory. This contains Mesa and I/O 
microcode, and Domino code (CP) 

=» Load the Germ into main memory (CP) 

^ Initialize the VIVI map (CP) 

^ Initialize the Mesa emulator (CP) 

Process "Mesa.db" (from main memory) file (lOP) 



® Transfer to Software booting 

start CP execution of Mesa, I/O microcode (lOP) 
=> Germ software starts executing (CP) 
Transfer to start of Domino code (lOP) 
=> Domino software starts executing (lOP) 

® Boot fifes location (rigid disk booting 



PhaseO boot file: located in EProm 

Initial boot file: located at fixed location on disk, 
stored in consecutive sectors [cyl 0, hd 1, sec on] 

Physical Volume Root Page (PVRP): 

points to rest of boot files 

located at fixed location on disk [cyl 0, hd 0, sec 0] 

contains pointers to: 

-> Mesa microcode boot file 

->Germ boot file 

-^ Diagnostic boot file 

-^ Software boot file (e.g. Othello) 



® Protected areas in CP 

- Control store and TPC images 

Low 128 locations in control store contain CP "vital" functions 

of lOP task code, memory refresh code, trap-catcher code, 

loop code 
Image of protected control store area is kept in lOP memory 
Image of TPC values is kept in lOP memory 
Images are transferred to CP at end of boot phase 
Vyriting control store and TPC values requires CP to be 

stopped AND requires careful CP-IOP interaction to avoid 

losing memory refresh 

Kernel microcode is never overlaid (32 locations) 



Detailed description of rigid disk booting 
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lOP 



Phase 



Initialize 

Run PreBoot diagnostics 

Process PhaseO.db 

Transfer CS image 

Transfer TPC Image 

Start CP kernel 

Start CP 
Determine boot device 



"•i^" 



CP 



CP kernel executes 

CP exits kernel (to Run state) 
Determine boot device 



Ptiase 1 



Walt for Flag 



Process Initial.db boot file 
(from main memory) 

Stop CP 

Transfer control store and 
TPC images 

Start CP 
[Start lOP] 



-s^ 



Read Initial.db from disk 
to main memory 
Set Flag in main memory 

Loop in protected area 



-^^ CP enters kernel 



•>^ CP exits kerne! (to Run state) 



Phase 2 



Wait for Flag 



Process Mesa.db boot file 
(from main memory) 

Stop CP 

Transfer control store and 
TPC images 

Start CP 
Start lOP 



Read Mesa.db from disk 
to main memory 
Read Germ from disk to memory 
Initialize VM map. Mesa emulator 
Set Flag In main memory 

Loop in protected area 
CP enters kernel 



->^ CP exits kernel (to Run state) 



Domino executes 



t 



Mesa emulator executes the Germ 



V 
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Other topics 
® Floppy booting 

Similar structure to rigid disk booting except that 
the boot device is directly accessible from the lOP 
The lOP processes boot files directly from the 
floppy disk 

® Ethernet booting (Etherbooting) 

Similar structure to rigid disk booting 

Boot files are fetched from boot server over the 
Ethernet 

© Diagnostic booting 

Allows the repeated execution of a collection of 
special boot diagnostics 

Diagnostics have total control of machine, but 
use the boot code to fetch and process boot files 

Implemented by repeating Phase 2 multiple times 
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Appendix 
@ Alternate boot codes 



AltBoot code 


Type of boot 





rigid* (diagnostic) 


1 


rigid* 


2 


floppy 


3 


ethernet 


4 


ethernet (diagnostic) 


5 


floppy (diagnostic) 


6 


alternate ethernet 


7 


Trident 1 (diagnostic) 


8 


Trident 2 (diagnostic) 


9 


Trident 3 (diagnostic) 


10 


floppy cleaning 



* AltBoot and 1 apply to the Shugart 1004, SA4008, 
Quantum, or Trident disk, whichever is installed in 
the system 



